In the current specifications of the third generation mobile networks (referred to as UMTS), the system utilises the same well-known architecture that has been used by all main second generation systems. A block diagram of the system architecture of the current UMTS network is presented in FIG. 1. The UMTS network architecture includes the core network (CN), the UMTS terrestrial radio access network (UTRAN), and the user equipment (UE). The core network is further connected to the external networks, i.e. the Internet, PSTN and/or ISDN.
The UTRAN architecture consists of several radio network subsystems (RNS). The RNS is further divided into the radio network controller (RNC) and several base stations (BTS, referred to as Node B in the 3GPP specifications). In this architecture there are several different connections between the network elements. The Iu interface connects CN to UTRAN. The Iur interface enables the exchange of signalling information between two RNCs. There is no equivalent interface to Iur in the architectures of the second generation mobile networks. The signalling protocol across the Iur interface is called the radio network subsystem application part (RNSAP). The RNSAP is terminated at both ends of the Iur interface by an RNC. The Iub interface connects an RNC and a Node B. The Iub interface allows the RNC and Node B to negotiate about radio resources, for example, to add and delete cells controlled by Node B to support communication of dedicated connection between UE and S-RNC, information used to control the broadcast and paging channels, and information to be transported on the broadcast and paging channels. One Node B can serve one or multiple cells. UE is connected to Node B through the Uu radio interface. UE further consists of a subscriber identity module (USIM) and mobile equipment (ME). They are connected by the Cu interface. Connections to external networks are made through Gateway MSC (towards circuit switched networks) or GGSN (towards packet switched networks).
The general protocol model for UTRAN Interfaces is depicted in FIG. 2, and described in detail in the following. The structure described is based on the principle that the layers and planes are logically independent of each other.
The Protocol Structure consists of two main layers, Radio Network Layer and Transport Network Layer. These are presented in the horizontal planes of FIG. 2. All UTRAN related issues are visible only in the Radio Network Layer, and the Transport Network Layer represents the standard transport technology that is selected to be used for UTRAN. UTRAN has certain specific requirements for TNL. For instance, the real time requirement, i.e. the transmission delay has to be controlled and kept small.
The Control Plane includes the Application Protocol, i.e. RANAP (RANAP, Radio Access Network Application Part), RNSAP (RNSAP, Radio Network Subsystem Application Part) or NBAP (NBAP, Node B Application Part), that is a part of RNL, and the Signalling Bearer, that is a part of TNL, for transporting the Application Protocol messages.
Among other things, the Application Protocol is used for setting up bearers (i.e. Radio Access Bearer or Radio Link) in the Radio Network Layer. In the three plane structure the bearer parameters in the Application Protocol are not directly tied to the User Plane transport technology, but are rather general bearer parameters.
The Signalling Bearer for the Application Protocol may or may not be of the same type as the Signalling Bearer for the ALCAP (ALCAP, Access Link Control Application Part). ALCAP is a generic name to indicate the protocol(s) used to establish data transport bearers on the Iu, Iur and Iub interfaces. AAL2 Signalling protocol Capability Set 2 (ITU-T Q.2630.2, a.k.aQ.aa12 CS-2) is the selected protocol to be used as ALCAP in UTRAN. Q.2630.2 adds new optional capabilities to Q.2630.1. The following should also be noted: data transport bearers may be dynamically established using ALCAP, or pre-configured and transport bearers may be established before or after allocation of radio resources. The Signalling Bearer is always set up by O & M (O & M, Operating and Maintenance) actions.
The User Plane Includes the Data Stream(s) and the Data Bearer(s) for the Data Stream(s). The Data Stream(s) is/are characterised by one or more frame protocols specified for that interface.
The Transport Network Control Plane does not include any Radio Network Layer information, and is completely in the Transport Layer. It includes the ALCAP protocol(s) that is/are needed to set up the transport bearers (Data Bearer) for the User Plane. It also includes the appropriate Signalling Bearer(s) needed for the ALCAP protocol(s) and for RANAP, RNSAP and NBAP protocols.
The Transport Network Control Plane is the Control plane of the Transport Network Layer. Its function is to control the transport bearers (setup/release/modify) in the Transport Network Layer. The introduction of the Transport Network Control Plane makes it possible for the Application Protocol in the Radio Network Control Plane to be completely independent of the technology selected for the Transport Bearer in the User Plane.
When a Transport Network Control Plane is used, the transport bearers for the Data Bearers in the RNL User Plane are set up in the following fashion. First there is a signalling transaction by the Application Protocol in the RNL Control Plane, which triggers the set up of the Data Bearer by the ALCAP protocol that is specific for the User Plane technology of the TNL.
The independence of RNL and TNL assumes that an ALCAP signalling transaction takes place. It should be noted that ALCAP might not be used for all types of Data Bearers. If there is no ALCAP signalling transaction, the Transport Network Control Plane is not needed at all. This is the case when pre-configured Data Bearers are used.
The Data Bearer(s) in the User Plane, and the Signalling Bearer(s) for the Application Protocol, belong also to the Transport Network User Plane. The Data Bearers in the Transport Network User Plane are directly controlled by the Transport Network Control Plane during a real time operation, but the control actions required for setting up the Signalling Bearer(s) for the Application Protocol are considered to be O&M actions.
The ATM Adaptation Layer (AAL) performs functions required by the user, control and management planes and supports the mapping between the ATM layer and the next higher layer. The functions performed in the AAL depend upon the higher layer requirements. In short, the AAL supports all the functions required to map information between the ATM network and the non-ATM application that may be using it. In UTRAN, the users of the AAL (i.e., the next higher layer) are the Radio Network Layer data streams, represented to AAL as Frame Protocol connections.
AAL 2 provides bandwidth-efficient transmission of low-rate, short and variable packets for delay sensitive applications, and is designed to make use of the more statistically multiplexable Variable Bit Rate ATM Traffic Classes. Therefore, AAL2 is not limited to ATM connections using the CBR Traffic Class, and can enable voice applications using higher layer requirements such as voice compression, silence detection/suppression, and idle channel removal. The structure of AAL2 allows network administrators to take traffic variations into account in the design of an ATM network and to optimise the network to match traffic conditions.
The ITU-T Recommendation Q.2630.2 AAL type 2 Signalling Protocol (Capability Set 2) specifies the inter-node protocol and nodal functions that control AAL type 2 point-to-point connections. FIG. 3 is showing an example of the use of Q.2630.2 in the UTRAN context, for the different interfaces. Further, the 3GPP Technical Specifications TS25.430 (chapter 4.5) and TS25.420 (chapter 6.4) specify the mapping between a transport channel (a Radio Network Layer object) and a transport bearer (a Transport Network Layer object). The rule is that there is a dedicated transport bearer for each Dedicated Channel (DCH) and for each individual user stream of the Downlink Shared Channel (DSCH). The users of Common Channels (Random Access Channel (RACH), Common Packet Channel (CPCH) and the Forward Access Channel (FACH)) can share a transport bearer.
The AAL2 transport bearers are established and released by AAL2 signalling, specified in ITU-T Recommendation Q.2630.2. The approach taken by 3GPP is a straightforward one; a new transport bearer is established on demand and released when the demand no longer exists.
In UMTS Release 4 the Transport Network Layer capabilities were further enhanced by replacing the Q.2630 Capability Set 1 with the Capability Set 2 (Q.2630.2). CS-2 has a connection modification capability that allows the modification of the characteristics of an existing AAL2 connection in a lightweight manner. This feature was specified to be used in cases where the bandwidth of the corresponding transport channel is changed, dramatically enough, during its lifetime.
In the current approach there is the following fundamental problem: the establishment and release of an AAL2 connection are heavier tasks than it was originally assumed. As a result the setup and release procedures take a longer time. It can be estimated that e.g., in certain UTRAN environments the setup delay can be a couple of hundred milliseconds at its maximum while in some specifications it has been (implicitly) assumed that it takes only some tens of milliseconds. The setup delay is dependent both on the Network Element implementation and on the transport network architecture.
The setup delay is a critical factor especially in case of transport channels conveying bursty packet traffic. In this case the lifetime of a transport channel can be very short, in the order of hundreds of milliseconds to some seconds. For the sake of efficiency in using the Radio Resources it is beneficial to minimise the setup delay of the transport bearers so that the Radio Resource Management decision to start using e.g., a DCH can be realised in as short time as possible and without any additional delay.
The objective of the present invention is to provide a method for the problem caused by a delay in the connection setup, specifically in the transport bearer setup as far as perceived by the Radio Network Layer (RNL). Furthermore, the objective of the present invention is, from the RNL and the radio resource utilisation viewpoints, to reduce the time it takes to make the underlying Iub and/or Iur transport bearer available as small as possible.
The invention is characterised by what is disclosed in the independent claims.